In certain operating systems, application code in an application context may sometimes need to utilize a kernel service to accomplish an operation. In a typical case, the application code sends a request to the kernel service. The kernel service then performs the requested operation on behalf of the application code, thereby enabling the application code to accomplish its operation through the kernel service.
The situation describes above can be managed with relative ease when both the application code and the kernel service reside in the same application context. To facilitate discussion, FIG. 1A shows an execution environment 20 including an application space 22 and a kernel space 24. Application code 26 is shown executing within an application context 28. As the term is employed herein, an application context represents an address (virtual memory point) and at least the application code. The application context may span both the application space and the kernel space. Within the same application context 28, there are shown two example kernel services: kernel service 30 and kernel service 32.
Application code 26 may sometimes require the use of kernel service 30 to accomplish a particular operation. In this case, application code 26 makes a call into kernel service 30 to request kernel service 30 to perform an operation on behalf of application code 26. In some cases, kernel service 30 may be able to perform the operation on behalf of application code 26 without calling on another kernel service. In other cases, kernel service 30 may require one or more other kernel services (such as kernel service 32) to perform yet other operations on behalf of kernel service 30. For example, kernel service 30 may need to access a file on the hard drive, and may utilize an I/O file service implemented by kernel service 32 to accomplish file I/O.
In the example of FIG. 1A, both kernel services 30 and kernel service 32 are local to application context 28 that is associated with application code 26. There are times, however, when one or more of the required kernel services do not exist in the same application context as the calling application code or the calling kernel service. FIGS. 1B and 1C show such examples. In FIG. 1B, remote kernel service 50 is shown residing in a different server context 52 from application context 28, which is associated with application code 26. In FIG. 1C, remote kernel service 70 is shown residing in a different server context 72 from application context 28, which is associated with application code 26 and the calling kernel service 74. As the term is employed herein, a server context represents an address space that resides in the kernel space and not in the application space.
When one or more of required kernel services are remote, i.e., they do not reside in the same application context as the calling application code or the calling kernel service, complications can arise with respect to signal handling by the various components and contexts involved in the operation if the remote kernel service is in the wait mode. A kernel service may be in a wait mode because it is waiting for some data or services, for example.
With respect to the example of FIG. 1C, remote kernel service 70 may need to obtain a particular data file from the hard drive on behalf of kernel service 74 (which may be asking for the data file on behalf of application code 26). Thus, remote kernel service 70 may issue a read command to the hard drive subsystem, and may enter a wait mode to wait for the data file to be returned by the hard drive subsystem. While remote kernel service 70 is in its wait mode, another component involved in the operation, such as application code 26 or kernel service 74 for example, may be receiving a signal that may require its immediate attention.
If the newly received signal requires the immediate attention of application code 26, for example, remote kernel service 70 may need to abort its current operation, thereby allowing other components involved in the pending operation (such as kernel service 74 and application code 26) to also abort. After all components successfully abort, the new signal can be attended to.
However, not all received signals merit aborting of the current operation. For example, aborting is not appropriate in all cases as a default response to a received signal. Accordingly, the handling of received signals while a remote kernel service is in its wait state needs to be carefully coordinated among the components and contexts involved in an operation to avoid inefficiency and/or to avoid error.
As mentioned earlier, when the kernel service is local to the calling application code or the calling kernel service (i.e., residing in the same application context), signal handling is relatively simple. Peculiarities pertaining to operating system (OS) organization and operation, which will be described herein, make such coordination challenging when one or more of the kernel services are remote. The coordination to facilitate efficient handling of signals received when a remote kernel service is in its wait state is the subject of this application.